Audio application programming interfaces (API's) may enable a wide variety of applications to set up complex audio processing graphs and to render audio output to a variety of different output devices. During processing of such a graph, it may be desirable to make a number of changes that modify the structure and/or state of the graph. For example, it may be desirable to add a new filter path to the graph. This may involve, for example, creating and adding a new voice and also a number of filters to mix points in the existing graph. Additionally, it may be desirable to modify a path of an existing filter. This may involve, for example, changing a source buffer of a voice, swapping filters, inserting new filters, or removing filters. A drawback of conventional audio API's is that they are limited with respect to their ability to allow changes to such graphs while the graphs are being processed without negatively affecting overall performance.
Audio API's may also have the ability to separate audio processing from rendering. This and other features of audio API's may create a number of clock synchronization issues that arise when an audio API is connected to audio rendering devices, applications, and processors that are using different clocks. For example, one problematic scenario may arise when a connected rendering device is consuming audio samples at a different rate than an audio API and/or a digital signal processor is producing the samples. Another problematic scenario may arise when the audio API is connected to a number of different rendering devices that are each consuming audio samples at a slightly different rate. Thus, another drawback of conventional audio API's is that they are limited with respect to their ability to coordinate clock synchronization among different connected audio rendering devices, applications, and processors.